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ABSTRACT 

Program  slicing  is  a  fundamental  operation  for  many  soft¬ 
ware  engineering  tools.  Currently,  the  most  efficient  algo¬ 
rithm  for  interprocedural  slicing  is  one  that  uses  a  program 
representation  called  the  system  dependence  graph.  This 
paper  defines  a  new  algorithm  for  slicing  with  system 
dependence  graphs  that  is  asymptotically  faster  than  the  pre¬ 
vious  one.  A  preliminary  experimental  study  indicates  that 
the  new  algorithm  is  also  significantly  faster  in  practice,  pro¬ 
viding  roughly  a  6-fold  speedup  on  examples  of  348  to  757 
lines. 

CR  Categories  and  Subject  Descriptors:  D.2.2  [Software 
Engineering];  Tools  and  Techniques  -  programmer  work¬ 
bench",  D.2.6  [Software  Engineering]:  Programming  Envi¬ 
ronments;  D.2.7  [Software  Engineering]:  Distribution  and 
Maintenance  -  enhancement,  restructuring;  E.l  [Data 
Structures]  graphs 

General  Terms:  Algorithms,  Performance 

Additional  Key  Words  and  Phrases:  dynamic  programming, 
dynamic  transitive  closure,  flow-sensitive  summary  informa¬ 
tion,  program  debugging,  program  dependence  graph,  pro¬ 
gram  slicing,  realizable  path 

1.  INTRODUCTION 

Program  slicing  is  a  fundamental  operation  for  many  soft¬ 
ware  engineering  tools,  including  tools  for  program  under¬ 
standing,  debugging,  maintenance,  testing,  and  integration 
[26,13,15,10,6,4].  Slicing  was  first  defined  by  Mark  Weiser, 
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who  gave  algorithms  for  computing  both  intra-  and  inter¬ 
procedural  slices  [26].  However,  two  aspects  of  Weiser’s 
interprocedural-slicing  algorithm  can  cause  it  to  include 
“extra”  program  components  in  a  slice: 

1.  A  procedure  call  is  treated  like  a  multiple  assignment 

statement  “vi,  V2, . . . ,  .^2, . . . ,  jc^”,  where  the 

V/  are  the  set  of  variables  that  might  be  modified  by  the 
call,  and  the  Xj  are  the  set  of  variables  that  might  be 
used  by  the  call.  Thus,  the  value  of  every  v/  after  the 
call  is  assumed  to  depend  on  the  value  of  every  Xj 
before  the  call.  This  may  lead  to  an  overly  conservative 
slice  (/.£.,  one  that  includes  extra  components)  as  illus¬ 
trated  in  Figure  1. 

2.  Whenever  a  procedure  P  is  included  in  a  slice,  all  calls 
to  P  (as  well  as  the  computations  of  the  actual  parame¬ 
ters)  are  included  in  the  slice.  An  example  in  which  this 
produces  an  overly  conservative  slice  is  given  in  Figure 
2. 

Interprocedural-slicing  algorithms  that  solve  the  two  prob¬ 
lems  illustrated  above  were  given  by  Horwitz,  Reps,  and 
Binkley  [14],  and  by  Hwang,  Du,  and  Chou  [16].  Hwang, 
Du,  and  Chou  give  no  analysis  of  their  algorithm’s  complex¬ 
ity;  however,  as  we  show  in  Appendix  A,  in  the  worst  case 
the  time  used  by  their  algorithm  is  exponential  in  the  size  of 
the  program.  By  contrast,  the  Horwitz-Reps-Binkley  algo¬ 
rithm  is  a  polynomial-time  algorithm. 

The  Horwitz-Reps-Binkley  algorithm  (summarized  in 
Section  2)  operates  on  a  program  representation  called  the 
system  dependence  graph  (SDG).  The  algorithm  involves 
two  steps:  first,  the  SDG  is  augmented  with  summary  edges, 
which  represent  transitive  dependences  due  to  procedure 
calls;  second,  one  or  more  slices  are  computed  using  the 
augmented  SDG.  The  two  steps  of  the  algorithm  (as  well  as 
the  construction  of  the  SDG)  require  time  polynomial  in  the 
size  of  the  program.  The  cost  of  the  first  step — computing 
summary  edges — dominates  the  cost  of  the  second  step. 

In  this  paper  we  define  a  new  algorithm  for  interprocedu¬ 
ral  slicing  using  SDGs  that  is  asymptotically  faster  than  the 
one  given  by  Horwitz,  Reps,  and  Binkley.  In  particular,  we 
present  an  improved  algorithm  for  computing  summary 
edges.  This  not  only  leads  to  a  faster  interprocedural-slicing 
algorithm,  but  is  also  important  for  all  other  applications 
that  use  system  dependence  graphs  augmented  with  sum¬ 
mary  edges  [5,18,7]. 

The  new  algorithm  is  presented  in  Section  3,  which  also 
discusses  its  asymptotic  complexity.  The  complexity  of  the 
new  algorithm  is  compared  to  that  of  the  Horwitz-Reps- 
Binkley  algorithm  in  Section  4.  Section  5  describes  some 
experimental  results  that  indicate  how  much  better  the  new 
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Example  program 

Precise  slice  from  “output(/)” 

Slice  using  Weiser’s  algorithm 

procedure  Main 

procedure  Main 

procedure  Main 

sum  :  =  0 

sum  :  =  0 

i  :  =  1 

z  :  =  1 

/  :  =  1 

while  /  <  1 1  do 

while  /  <  1 1  do 

while  /  <  1 1  do 

call  A(sum,  i) 

call  A(z) 

call  A{sum,  i) 

od 

od 

od 

output(5wm) 

output(/) 

output(/) 

output(/) 

end 

end 

end 

procedure  A{x,  y) 

procedure  A(y) 

procedure  A{x,  y) 

X :  =  x  +  y 
y.  =  y+l 

y:  =  y+l 

y:  =  y+l 

return 

return 

return 

Figure  1.  An  example  program,  its  slice  with  respect  to  “output(/)”,  and  the  slice  computed  using  Weiser’s  algorithm. 


Example  program 

Precise  slice  from  “output(z)” 

Slice  using  Weiser’s  algorithm 

procedure  Main 

procedure  Main 

procedure  Main 

sum  :  =  0 

sum  :  =  0 

z  :  =  I 

z  :  =  1 

z  :  =  I 

while  z  <  1 1  do 

while  z  <  1 1  do 

while  z  <  1 1  do 

call  Add(sum,  i) 

call  AddisumJ) 

call  Add(i,  1) 

call  Add{i,  1) 

can  Adda  A) 

od 

od 

od 

output(5zzm) 

output(z) 

output(z) 

output(z) 

end 

end 

end 

procedure  Add{x,  y) 

procedure  Addix,  y) 

procedure  Addix,  y) 

jc :  =  JC4-y 

x:  =  x  +  y 

x'.-x  +  y 

return 

return 

return 

Figure  2.  An  example  program,  its  slice  with  respect  to  “output(i)'’,  and  the  slice  computed  using  Weiser’s  algorithm. 


slicing  algorithm  is  than  the  old  one:  when  implementations 
of  the  two  algorithms  were  used  to  compute  slices  for  three 
example  programs  (which  ranged  in  size  from  348  to  757 
lines)  the  new  algorithm  exhibited  roughly  a  6-fold  speedup. 

2.  BACKGROUND:  INTERPROCEDURAL  SLICING 
USING  SYSTEM  DEPENDENCE  GRAPHS 

2.1.  System  Dependence  Graphs 

System  dependence  graphs  were  defined  in  [14].  Due  to 
space  limitations  we  will  not  give  a  detailed  definition  here; 
the  important  ideas  should  be  clear  from  the  examples.  A 
program’s  system  dependence  graph  (SDG)  is  a  collection 
of  procedure  dependence  graphs  (PDGs):  one  for  each  pro¬ 
cedure.  The  vertices  of  a  PDG  represent  the  individual 
statements  and  predicates  of  the  procedure.  A  call  statement 
is  represented  by  a  call  vertex  and  a  collection  of  actual-in 
and  actual-out  vertices:  there  is  an  actual-in  vertex  for  each 
actual  parameter,  and  there  is  an  actual-out  vertex  for  each 
actual  parameter  that  might  be  modified  during  the  call. 


Similarly,  procedure  entry  is  represented  by  an  entry  vertex 
and  a  collection  of  formal-in  and  formal-out  vertices. 
(Global  variables  are  treated  as  “extra”  parameters,  and  thus 
give  rise  to  additional  actual-in,  actual-out,  formal-in,  and 
formal-out  vertices.)  The  edges  of  a  PDG  represent  the  con¬ 
trol  and  flow  dependences  among  the  procedure’s  statements 
and  predicates.*  The  PDGs  are  connected  together  to  form 
the  SDG  by  call  edges  (which  represent  procedure  calls,  and 
run  from  a  call  vertex  to  an  entry  vertex)  and  by  parameter- 
in  and  parameter-out  edges  (which  represent  parameter 
passing,  and  which  run  from  an  actual-in  vertex  to  the  corre¬ 
sponding  formal-in  vertex,  and  from  a  formal-out  vertex  to 


‘  As  defined  in  [14],  procedure  dependence  graphs  include  four  kinds  of 
dependence  edges:  control,  loop-independent  flow,  loop-carried  flow,  and 
def-order.  However,  for  slicing  the  distinction  between  loop-independent 
and  loop-carried  flow  edges  is  irrelevant,  and  def-order  edges  are  not  used. 
Therefore,  in  this  paper  we  assume  that  PDGs  include  only  control  edges 
and  a  single  kind  of  flow  edge. 


all  corresponding  actual-out  vertices,  respectively). 

Example.  Figure  3  shows  the  SDG  for  the  program  of 
Figure  2.  D 

We  wish  to  point  out  that  SDGs  are  really  a  class  of  pro¬ 
gram  representations.  To  represent  programs  in  different 
programming  languages  one  would  use  different  kinds  of 
PDGs,  depending  on  the  features  and  constructs  of  the  given 
language.  Although  our  running  example  and  the  experi¬ 
ments  reported  in  Section  5  use  a  very  simple  programming 
language,  the  reader  should  keep  in  mind  that  we  use  the 
term  “SDG”  in  this  generic  sense;  in  particular,  our  results 
should  not  be  thought  of  as  being  tied  to  the  restricted  lan¬ 
guage  used  in  our  examples.  The  superiority  of  the  algo¬ 
rithm  given  in  Section  3  over  previous  interprocedural  slic¬ 
ing  algorithms  will  almost  certainly  hold  no  matter  what  the 
features  and  constructs  of  the  language  to  which  it  is 
applied.^ 

2.2.  Interprocedural  Slicing 

Ottenstein  and  Ottenstein  showed  that  m/raprocedural  slices 
can  be  obtained  by  solving  a  reachability  problem  on  the 


PDG:  to  compute  the  slice  with  respect  to  PDG  vertex  v, 
find  all  PDG  vertices  from  which  there  is  a  path  to  v  along 
control  and/or  flow  edges  [22].  Interpvoceduved  slices  can 
also  be  obtained  by  solving  a  reachability  problem  on  the 
SDG;  however,  the  slices  obtained  using  this  approach  will 
include  the  same  “extra”  components  as  illustrated  in  col¬ 
umn  3  of  Figure  2.  This  is  because  not  all  paths  in  the  SDG 
correspond  to  possible  execution  paths.  For  example,  there 
is  a  path  in  the  SDG  shown  in  Figure  3  from  the  vertex  of 
procedure  Main  labeled  ''sum :  =  0”  to  the  vertex  of  Main 
labeled  “output(/).”  However,  this  path  corresponds  to  an 
“execution”  in  which  procedure  Add  is  called  from  the  first 
call  site  in  Main,  but  returns  to  the  second  call  site  in  Main, 
which  is  not  a  legal  call/return  sequence.  The  final  value  of 
i  in  Main  is  independent  of  the  value  of  sum,  and  so  the  ver¬ 
tex  labeled  "sum: -O'"  should  not  be  included  in  the  slice 
with  respect  to  the  vertex  labeled  “output(i)”. 

Instead  of  considering  all  paths  in  the  SDG,  the  computa¬ 
tion  of  a  slice  must  consider  only  realizable  paths:  paths  that 
reflect  the  fact  that  when  a  procedure  call  finishes,  execution 


Edge  Key 
control  edge 
-►  flow  edge 
call, 

parameter-in,  or 

parameter-out 

edge 


output 


Figure  3.  The  SDG  for  the  program  of  Figure  2. 


“The  issue  of  how  to  create  appropriate  PDGs/SDGs  is  orthogonal  to  the 
issue  of  how  to  slice  them.  Previous  work  has  investigated  how  to  build 
dependence  graphs  for  the  features  and  constructs  found  in  real-world  pro¬ 
gramming  languages.  For  example,  previous  work  has  addressed  arrays 
[3,27,21,1 1,23,24],  reference  parameters  [14],  pointers  [20,12,8],  and  non- 
structured  control  flow  [2,9,1]. 


sum  :  =  0  Xin  :  =  sum  x  :  -  jc  :  =  jc  +  y 

x^,nf  :  =  X  sum  :  =  — >  output(5Mm) 

is  a  (same-level)  realizable  path,  while  the  path 

sum  :  =  0  Xifj  :  =  sum  -»  x  :  =  Xi^  — ^  jc  :  =  jc  -t-  y 

— >  :  =  X  —>  / :  =  Xout  output(/) 

is  not.  □ 


returns  to  the  site  of  the  most  recently  executed  call.^ 

Definition  (realizable  paths).  Let  each  call  vertex  in  SDG 
G  be  given  a  unique  index  from  1  to  k.  For  each  call  site  C/, 
label  the  outgoing  parameter-in  edges  and  the  incoming 
parameter-out  edges  with  the  symbols  “(/”  and  “)/”»  respec¬ 
tively;  label  the  outgoing  call  edge  with  “(/”• 

A  path  in  G  is  a  same^level  realizable  path  iff  the 
sequence  of  symbols  labeling  the  parameter-in,  parameter- 
out,  and  call  edges  in  the  path  is  a  string  in  the  language  of 
balanced  parentheses  generated  from  nonterminal  matched 
by  the  following  context-free  grammar: 

matched  matched  matched  ),  for  1  <  /  <  /: 

1  s 

A  path  in  C  is  a  realizable  path  iff  the  sequence  of  sym¬ 
bols  labeling  the  parameter-in,  parameter-out,  and  call  edges 
in  the  path  is  a  string  in  the  language  generated  from  nonter¬ 
minal  realizable  by  the  following  context-free  grammar 
(where  matched  is  as  defined  above): 

realizable  realizable  (,  matched  fov\<i<k 
I  matched 

□ 

Example.  In  Figure  3,  the  path 


An  interprocedural-slicing  algorithm  is  precise  up  to  real¬ 
izable  paths  if,  for  a  given  vertex  v,  it  determines  the  set  of 
vertices  that  lie  on  some  realizable  path  from  the  entry  ver¬ 
tex  of  the  main  procedure  to  v.  To  achieve  this  precision, 
the  Horwitz-Reps-Binkley  algorithm  first  augments  the 
SDG  with  summary  edges,  A  summary  edge  is  added  from 
actual-in  vertex  v  (representing  the  value  of  actual  parame¬ 
ter  X  before  the  call)  to  actual-out  vertex  w  (representing  the 
value  of  actual  parameter  y  after  the  call)  whenever  there  is 
a  same-level  realizable  path  from  v  to  w.  The  summary 
edge  represents  the  fact  that  the  value  of  y  after  the  call 
might  depend  on  the  value  of  x  before  the  call.  Note  that  a 
summary  edge  cannot  be  computed  simply  by  determining 
whether  there  is  a  path  in  the  SDG  from  v  to  w  {e.g.,  by  tak¬ 
ing  the  transitive  closure  of  the  SDG’s  edges).  That 
approach  would  be  imprecise  for  the  same  reason  that  tran¬ 
sitive  closure  leads  to  imprecise  interprocedural  slicing, 


Figure  4.  The  SDG  of  Figure  3,  augmented  with  summary  edges  and  sliced  with  respect  to  “output{/)”. 


similar  goal  of  considering  only  paths  that  correspond  to  legal 
call/retum  sequences  arises  in  the  context  of  interprocedural  dataflow 
analysis  [25,19].  Several  different  terms  have  been  used  for  these  paths, 
including  valid  paths,  feasible  paths,  and  realizable  paths. 


namely  that  not  all  paths  in  the  SDG  are  realizable  paths. 

After  adding  summary  edges,  the  Horwitz-Reps-Binkley 
slicing  algorithm  uses  two  passes  over  the  augmented  SDG; 
each  pass  traverses  only  certain  kinds  of  edges.  To  slice  an 
SDG  with  respect  to  vertex  v,  the  traversal  in  Pass  1  starts 
from  V  and  goes  backwards  (from  target  to  source)  along 
flow  edges,  control  edges,  call  edges,  summary  edges,  and 
parameter-in  edges,  but  not  along  parameter-out  edges.  The 
traversal  in  Pass  2  starts  from  all  actual-out  vertices  reached 
in  Pass  1  and  goes  backwards  along  flow  edges,  control 
edges,  summary  edges,  and  parameter-out  edges,  but  not 
along  call  or  parameter-in  edges.  The  result  of  an  interpro¬ 
cedural  slice  consists  of  the  set  of  vertices  encountered  dur¬ 
ing  Pass  1  and  Pass  2,  and  the  edges  induced  by  those 
vertices."^ 

Example.  Figure  4  gives  the  SDG  of  Figure  3  augmented 
with  summary  edges,  and  shows  the  vertices  and  edges  tra¬ 
versed  during  the  two  passes  when  slicing  with  respect  to 
the  vertex  labeled  “output(/).”  □ 

3.  AN  IMPROVED  ALGORITHM  FOR  COMPUTING 
SUMMARY  EDGES 

This  section  contains  the  main  result  of  the  paper:  a  new 
algorithm  for  computing  summary  edges  that  is  asymptoti¬ 
cally  faster  than  the  one  defined  by  Horwitz,  Reps,  and 
Binkley.  (We  will  henceforth  refer  to  the  latter  as  the  HRB~ 
summary  algorithm.) 

The  new  algorithm  for  computing  summary  edges  is 
given  in  Figure  5  as  function  Computes  ummary Edges, 
(Computes ummary Edges  uses  several  auxiliary  access 
functions:  function  Proc  returns  the  procedure  that  contains 
the  given  SDG  vertex;  function  Callers  returns  the  set  of 
procedures  that  call  the  given  one;  function  Correspondin- 
gActualln  (and  CorrespondingActualOut)  returns  the  actual- 
in  (or  actual-out)  vertex  associated  with  the  given  call  site 
that  corresponds  to  the  given  formal-in  (or  formal-out)  ver¬ 
tex.)  Figure  6  illustrates  schematically  the  key  steps  of  the 
algorithm.  The  basic  idea  is  to  find,  for  every  procedure  P, 
ail  same-level  realizable  paths  that  end  at  one  of  P’s  formal- 
out  vertices.  Those  paths  that  start  from  one  of  P’s  formal¬ 
in  vertices  induce  summary  edges  between  the  correspond¬ 
ing  actual-in  and  actual-out  vertices  at  all  call  sites  that  rep¬ 
resent  calls  to  P.  (For  example,  if  the  algorithm  were 
applied  to  the  SDG  shown  in  Figure  3,  a  path  would  be 
found  from  the  formal-in  vertex  of  procedure  Add  labeled 
=  to  the  formal-out  vertex  labeled  :=jc”. 
This  path  would  induce  the  summary  edges  from 
=  to  ''sum  :=  and  from  "Xin\  =  r  to 

"i  :  =  in  Main,  as  shown  in  Figure  4.) 


“^The  augmented  SDG  can  also  be  used  to  compute  a  forward  (interproce¬ 
dural)  slice  using  two  edge-traversal  passes,  where  each  pass  traverses  on¬ 
ly  certain  kinds  of  edges;  however,  in  a  forward  slice  edges  are  traversed 
from  source  to  target.  The  first  pass  of  a  forward  slice  ignores  parameter- 
in  and  call  edges;  the  second  pass  ignores  parameter-out  edges. 


In  the  algorithm,  same-level  realizable  paths  are  repre¬ 
sented  by  “path  edges”,  the  edges  that  are  inserted  into  the 
set  called  PathEdge.  The  algorithm  starts  by  “asserting” 
that  there  is  a  same-level  realizable  path  from  every  formal- 
out  vertex  to  itself;  these  path  edges  are  inserted  into 
PathEdge,  and  also  placed  on  the  worklist.  Then  the  algo¬ 
rithm  finds  new  path  edges  by  repeatedly  choosing  an  edge 
from  the  worklist  and  extending  (backwards)  the  path  that  it 
represents  as  appropriate  depending  on  the  type  of  the 
source  vertex.  This  is  illustrated  in  Figure  6.  When  a  path 
edge  is  processed  whose  source  is  a  formal-in  vertex,  the 
corresponding  summary  edges  are  inserted  into  the  Summa¬ 
ry  Edge  set  (lines  [16]-[19]).  These  new  summary  edges 
may  in  turn  induce  new  path  edges:  if  there  is  a  summary 
edge  x^y,  then  there  is  a  same-level  realizable  path 
X  — y  a  for  every  formal-out  vertex  a  such  that  there  is  a 
same-level  realizable  path  y — y  a.  Therefore,  procedure 
Propagate  is  called  with  all  appropriate  x — edges  (lines 
[20]-[22]). 

The  cost  of  the  algorithm  can  be  expressed  in  terms  of  the 
following  parameters: 


p 

The  number  of  procedures  in  the  pro¬ 
gram. 

Sites  p 

The  number  of  call  sites  in  procedure  p. 

Sites 

The  maximum  number  of  call  sites  in 
any  procedure. 

TotalSites 

The  total  number  of  call  sites  in  the  pro¬ 
gram.  (This  is  bounded  by  P  x  Sites.) 

E 

The  maximum  number  of  control  and 
flow  edges  in  any  procedure’s  PDG. 

Params 

The  maximum  number  of  formal-in  ver¬ 
tices  in  any  procedure’s  PDG. 

The  algorithm  finds  all  same-level  realizable  paths  that  end 
at  a  formal-out  vertex  vv.  A  new  path  jc  — y  w  is  found  by 
extending  (backwards)  a  previously  discovered  path  v  — vv 
(taken  from  the  worklist)  along  the  edge  x  — >  v.  Because 
vertex  .x  can  have  out-degree  greater  than  one,  the  same  path 
can  be  discovered  more  than  once  (but  it  will  only  be  put  on 
the  worklist  once,  due  to  the  test  in  Propagate). 

In  the  worst  case,  the  algorithm  will  “extend  a  path” 
along  every  PDG  edge  (lines  [27]-[29])  and  every  summary 
edge  (lines  [11]”[13]  and  [20]-[22])  once  for  each  formal- 
out  vertex.  Thus,  the  cost  of  computing  summary  edges  for 
a  single  procedure  is  equal  to  the  number  of  formal-out  ver¬ 
tices  (bounded  by  Params)  times  the  number  of  PDG  and 
summary  edges  in  that  procedure.  In  the  worst  case,  there  is 
a  summary  edge  from  every  actual-in  vertex  to  every  actual- 
out  vertex  associated  with  the  same  call  site.  Therefore,  the 
number  of  summary  edges  in  procedure  p  is  bounded  by 
0(SiteSp  X  Params^),  and  the  cost  of  computing  summary 
edges  for  one  procedure  is  bounded  by 
0(Params  x  (£"  +  {Sites ^  x  Params^))),  which  is  equal  to 
0{{Params  x  E)  +  {Sites ^  x  Params^)).  Summing  over 
all  procedures  in  the  program,  the  total  cost  of  the  algorithm 
is  bounded  by 


function  ComputeSummaryEdges(G:  SDG)  returns  set  of  edges 
declare  PathEdge,  SummaryEdge,  WorkList:  set  of  edges 

procedure  Propagate(^:  edge) 
begin 

[1]  if  ^  ^  PathEdge  then  insert  e  into  PathEdge;  insert  e  into  WorkList  fi 

end 

begin 

[2]  PathEdge  0;  SummaryEdge  :=  0;  WorkList  :=  0 

[3]  for  each  w  e  FormalOutVertices{G) 

[4]  insert  (w  w)  into  PathEdge 

[5]  insert  (w^  — >  vv;)  into  WorkList 

[6]  od 

[7]  while  WorkList  ^0  do 

[8]  select  and  remove  an  edge  v  — >  w  from  WorkList 

[9]  switch  V 

[10]  case  V  e  ActualOutVertices(G) : 

[11]  for  each  x  such  that  x—>ve  {SummaryEdge  u  ControlEdgesiG))  do 

[  1 2]  Propagate(jc  — >  w) 

[13]  od 

[14]  end  case 

[15]  case  v  €  FormallnVertices{G) : 

[16]  for  each  c  €  Callers{Proc{w))  do 

[17]  let  jc  =  CorrespondingActuaIIn(c,  v) 

[18]  y  =  CorrespondingActualOutCc,  w)  in 

[  1 9]  insert  x  — >  y  into  SummaryEdge 

[20]  for  each  a  such  that  y  — >  a  e  PathEdge  do 

[21]  Propagate(^  — ^ 

[22]  od 

[23]  end  let 

[24]  od 

[25]  end  case 

[26]  default : 

[27]  for  each  x  such  that  jc  — >  v  g  {FlowEdges{G)  u  ControlEdgesiG))  do 

[28]  Propagate(jc  — >  w) 

[29]  od 

[30]  end  case 

[3 1  ]  end  switch 

[32]  od 

[33]  retum(SummaryEdge) 
end 


Figure  5.  Function  ComputeSummaryEdges  computes  and  returns  the  set  of  summary  edges  for  the  given  system  dependence  graph  G 
(See  also  Figure  6.) 


0{{P  X  Params  x  £)  +  {TotalSites  x  Params^)). 

4.  COMPARISON  WITH  PREVIOUS  WORK 

The  cost  of  interprocedural  slicing  using  the  algorithm  of 
Horwitz,  Reps,  and  Binkley  is  dominated  by  the  cost  of 
computing  summary  edges  via  the  HRB-summary  algorithm 
(see  [14]): 

0{{TotalSites  x  E  x  Params) 

+  (TotalSites  x  Sites^  x  Params^^)). 

The  main  result  of  this  paper  is  a  new  algorithm  for  comput¬ 
ing  summary  edges  whose  cost  is  bounded  by 


0{(P  X  E  X  Params)  +  (TotalSites  x  Params^)), 

Under  the  reasonable  assumption  that  the  total  number  of 
call  sites  in  a  program  is  much  greater  than  the  number  of 
procedures,  each  term  of  the  cost  of  the  new  algorithm  is 
asymptotically  smaller  than  the  corresponding  term  of  the 
cost  of  the  HRB-summary  algorithm.  Furthermore,  because 
there  is  a  family  of  examples  on  which  the  HRB-summary 
algorithm  actually  performs 

Q((TotalSites  x  E  x  Params) 

+  (TotalSites  x  Sites^  x  Params^)) 

steps,  the  new  algorithm  is  asymptotically  faster. 

There  are  two  main  differences  in  the  approaches  taken 
by  the  two  algorithms  that  lead  to  the  differences  in  their 


costs: 


1.  The  HRB-summary  algorithm  first  creates  a  “com¬ 
pressed”  form  of  the  SDG  that  contains  only  formal-in, 
formal-out,  actual-in,  and  actual-out  vertices.  The  edges 
of  the  compressed  graph  represent  (intraprocedural) 
paths  in  the  original  graph.  The  cost  of  compressing  the 
SDG  is  0{TotalSites  x  E  x  Params),  the  first  term  in 
the  cost  given  above.  The  new  algorithm  uses  the 
uncompressed  SDG,  so  there  is  no  compression  cost. 

2.  After  compressing  the  SDG,  the  HRB-summary  algo¬ 
rithm  repeatedly  finds  and  installs  summary  edges,  then 
closes  the  edge  set  of  the  PDG.  These  “install-and- 
close”  steps  are  similar  to  the  “extend-a-path”  steps  that 
are  performed  by  the  new  algorithm.  The  difference  is 
that  the  “close”  step  of  the  HRB-summary  algorithm 
essentially  replaces  a  3-part  path  of  the  form 
“path:edge:path”  with  a  single  path  edge,  while  the  new 
algorithm  replaces  a  2-part  path  of  the  form  “edge:path” 
with  a  single  path  edge.  The  latter  approach  is  a  second 
reason  for  the  superiority  of  the  new  algorithm.  The 
total  cost  of  the  series  of  “install-and-close”  steps  per¬ 
formed  by  the  HRB-summary  algorithm  is 
0{TotalSites  x  Sites^  x  Params"^),  the  second  term  in 
the  cost  given  above.  This  term  is  likely  to  be  the  domi¬ 
nant  term  in  practice,  and  it  is  worse  (by  a  factor  of 
Sites^  X  Params)  than  the  second  term  in  the  new  algo¬ 
rithm’s  cost. 

To  summarize:  Both  the  cost  of  the  HRB-summary  algo¬ 
rithm  and  the  cost  of  the  new  algorithm  contain  two  terms. 
In  the  case  of  the  former,  the  first  term  represents  the  cost  of 
compression,  and  the  second  term  represents  the  cost  of 
finding  summary  edges  using  the  compressed  graph.  In  the 
case  of  the  latter,  both  terms  represent  the  cost  of  finding 
summary  edges  using  the  uncompressed  graph.  The  cost  of 
the  new  algorithm  is  asymptotically  better  than  the  cost  of 
the  HRB-summary  algorithm. 

5.  EXPERIMENTAL  RESULTS 

This  section  describes  the  results  of  a  preliminary  perfor¬ 
mance  study  we  carried  out  to  measure  how  much  faster 
interprocedural  slicing  is  when  function  ComputeSumma- 
ry Edges  is  used  in  place  of  the  HRB-summary  algorithm. 
The  slicing  algorithms  were  implemented  in  C  and  tested  on 
a  Sun  SPARCstation  10  Model  30  with  32  MB  of  RAM. 
Tests  were  carried  out  for  three  example  programs  (written 
in  a  small  language  that  includes  scalar  variables,  array  vari¬ 
ables,  assignment  statements,  conditional  statements,  output 
statements,  while  loops,  for  loops,  and  procedures  with 
value-result  parameter  passing):  recdes  is  a  recursive- 
descent  parser  for  lists  of  assignment  statements;  calc  is  a 
simple  arithmetic  calculator;  znd  format  is  a  text- formatting 
program  taken  from  Kernighan  and  Plauger’s  book  on  soft¬ 
ware  tools  [17].  The  following  table  gives  some  statistics 
about  the  SDGs  of  the  three  test  programs: 


Prog. 

Lines 

of 

source 

SDG  statistics  | 

Ver¬ 

tices 

Control 
+  flow 
edges 

P 

Sites 

TotalSites 

E 

Params 

recdes 

348 

838 

1465 

15 

13 

60 

255 

8 

:alc 

433 

841 

1443 

24 

26 

70 

409 

12 

format 

757 

1844 

3276 

53 

20 

108 

597 

23 

The  comparison  in  Section  4  of  the  asymptotic  worst-case 
running  time  of  the  HRB-summary  algorithm  with  that  of 
the  new  algorithm  suggests  that  the  new  algorithm  should 
lead  to  a  significantly  better  slicing  algorithm.  However, 
formulas  for  asymptotic  worst-case  running  time  may  not  be 
good  predictors  of  actual  performance.  For  example,  the 
formula  for  the  running  time  of  ComputeSummaryEdges 
was  derived  under  the  (worst-case)  assumptions  that  there  is 
a  summary  edge  from  every  actual-in  vertex  to  every  actual- 
out  vertex  associated  with  the  same  call  site,  and  that  every 
call  site  has  the  same  number  of  actual-in  and  actual-out 
vertices — both  of  which  are  bounded  by  Params,  This 
yields  0{TotalSites  x  Params^)  as  the  bound  on  the  total 
number  of  summary  edges.  As  shown  in  the  following 
table,  this  overestimates  the  actual  number  of  summary 
edges  by  one  to  two  orders  of  magnitude: 


Example 

TotalSites  x  Params^ 

Actual  number  of 
summary  edges 

recdes 

3840 

157 

calc 

10080 

227 

format 

57132 

413 

Thus,  although  asymptotic  worst-case  analysis  may  be  help¬ 
ful  in  guiding  algorithm  design,  tests  are  clearly  needed  to 
determine  how  well  a  slicing  algorithm  performs  in  practice. 

For  our  study,  we  implemented  three  different  slicing 
algorithms:  (A)  the  Horwitz-Reps-Binkley  slicing  algo¬ 
rithm,  (B)  the  slicing  algorithm  with  the  improved  method 
for  computing  summary  edges  from  Section  3,  and  (C)  an 
algorithm  that  is  essentially  the  “dual”  of  Algorithm  B. 
Algorithm  C  is  just  like  Algorithm  B,  except  that  the  com¬ 
putation  of  summary  edges  involves  finding  all  same-level 
realizable  paths /ram  formal-in  vertices  (rather  than  to  for- 
mal-out  vertices),  and  paths  are  extended  forwards  rather 
than  backwards. 

The  table  shown  in  Figure  7  gives  statistics  about  the  per¬ 
formance  of  the  three  algorithms  for  a  representative  slice  of 
each  of  the  three  programs.  In  each  case,  the  reported  run¬ 
ning  time  is  the  average  of  five  executions.  (The  quantity 
“Time  to  slice”  is  “user  cpu-time  +  system  cpu-time”.)  The 
time  for  the  final  step  of  computing  slices — the  two-pass 
traversal  of  the  augmented  SDG — is  not  shown  as  a  separate 
entry  in  the  table;  this  step  is  a  relatively  small  portion  of  the 
time  to  slice:  .03-.04  seconds  (of  total  cpu-time)  for  both 
recdes  and  calc;  .20-. 23  seconds  for  format. 

As  shown  in  columns  6  and  8  of  the  above  table.  Algo¬ 
rithms  B  and  C  are  clearly  superior  to  Algorithm  A,  exhibit¬ 
ing  4.8-fold  to  6.5-fold  speedup.  Algorithm  B  appears  to  be 


Lines  [16] -[191 


KEY 

^  control  or  flow  edge 


path  edge 

(possibly  new)  path  edge 

summary  edge 

new  summary  edge 

parameter-in  or 
parameter-out  edge 


Figure  6.  The  above  four  diagrams  show  how  the  algorithm  of  Figure  5  extends  same-level  realizable  paths,  and  installs  summary  edges. 


Algorithm  B 

Algorithm  C 

Example 

Vertices  in  slice 

HRB  slicing 
algorithm 

Summary  edges  computed 
by  the  algorithm  of 

Section  3 

Summary  edges  computed 
by  the  dual  of  the 
algorithm  of  Section  3 

Number 

Percent 
of  total 

Time  to  slice 
(seconds) 

Time  to  slice 
(seconds) 

Speedup 
(over  HRB) 

Speedup 
(over  HRB) 

recdes 

413 

49% 

2.08  +  0,04 

0.35  +  0.04 

5.4 

4.8 

calc 

484 

58% 

3.06  +  0.05 

0.46  +  0.03 

6.3 

0.45  +  0.03 

6.5 

format 

1327 

72% 

6.64 -H  0.1 2 

0.98  +  0.12 

6.1 

1.09  +  0.16 

5.4 

Figure  7.  Performance  of  the  three  algorithms  for  a  representative  slice  of  each  of  the  three  example  programs. 


marginally  better  than  Algorithm  C.  We  believe  that  this  is 
because  procedures  have  fewer  formal-out  vertices  than  for¬ 
mal-in  vertices. 

Because  the  bound  derived  for  the  series  of  “install-and- 
close”  steps  of  Algorithms  B  and  C  is  better  than  the  bound 
for  the  HRB-summary  algorithm  by  a  factor  of 
Sites^  X  Params,  the  speedup  factor  may  be  greater  on 
larger  programs.  As  a  preliminary  test  of  this  hypothesis, 
we  gathered  some  statistics  on  versions  of  the  above  pro¬ 
grams  in  which  the  number  of  parameters  was  artificially 
inflated  (by  adding  additional  global  variables).  On  these 
examples,  Algorithm  C  exhibited  10- fold  speedup  over  the 
Horwitz-Reps-Binkley  slicing  algorithm,  and  Algorithm  B 
exhibited  13-fold  to  23-fold  speedup. 

In  summary:  the  conclusion  that  the  algorithm  presented 
in  this  paper  is  significantly  better  than  the  Horwitz-Reps- 
Binkley  interprocedural-slicing  algorithm  is  supported  both 
by  comparison  of  asymptotic  worst-case  running  times  (see 


Section  4)  and  preliminary  experimental  results. 

APPENDIX  A;  Demonstration  that  the  Algorithm  of 
Hwang,  Du,  and  Chou  is  Exponential 

The  Hwang-Du-Chou  algorithm  constructs  a  sequence  of 
slices  of  the  program — where  each  slice  in  the  sequence 
essentially  permits  one  additional  level  of  recursion — until  a 
fixed  point  is  reached  {ie,,  until  no  further  elements  are 
included  in  a  slice).  In  essence,  to  compute  a  slice  with 
respect  to  a  point  in  procedure  P,  it  is  as  if  the  algorithm 
performs  the  following  sequence  of  steps: 

1.  Replace  each  call  in  procedure  P  with  the  body  of  the 
called  procedure. 

2.  Compute  the  slice  using  the  new  version  of  P  (and 
assume  that  there  are  no  flow  dependences  across  unex¬ 
panded  calls). 


3.  Repeat  steps  1  and  2  until  no  new  vertices  are  included 
in  the  slice,  (For  the  purposes  of  determining  whether  a 
new  vertex  is  included  in  the  slice,  each  vertex  instance 
in  the  expanded  program  is  identified  with  its  “originat¬ 
ing  vertex”  in  the  original,  multi-procedure  program.) 

In  fact,  no  actual  in-line  expansions  are  performed;  instead 
they  are  simulated  using  a  stack.  On  the  slice  of  the 
sequence,  there  is  a  bound  of  k  on  the  depth  of  the  stack. 
Because  the  stack  is  used  to  keep  track  of  the  calling  context 
of  a  called  procedure,  only  realizable  paths  are  considered. 

In  this  appendix,  we  present  a  family  of  examples  on 
which  the  Hwang-Du-Chou  algorithm  takes  exponential 
time.  In  order  to  simplify  the  presentation  of  this  family  of 
programs,  we  will  streamline  the  diagrams  of  the  SDGs  we 
use  by  including  only  vertices  related  to  procedure  calls 
(enter,  formal-in,  formal-out,  call,  actual-in,  and  actual-out 
vertices)  and  the  intraprocedural  transitive  dependences 
among  them.  (This  streamlining  does  not  affect  our  argu¬ 
ment,  and  showing  complete  SDGs  would  make  our  dia¬ 
grams  unreadable.) 

Theorem.  There  is  a  family  of  programs  on  which  the 
Hwang-Du-Chou  algorithm  uses  time  exponential  in  the  size 
of  the  program. 

Proof.  We  construct  a  family  of  programs  that  grows 
linearly  in  size  with  k  but  causes  the  Hwang-Du-Chou  algo¬ 
rithm  to  use  time  exponential  in  the  size  of  k  {i.e.,  the  algo¬ 
rithm’s  running  time  is  Q(2^)). 

A  given  program  in  the  family  consists  of  just  a  single 
recursive  procedure  (also  named  P^),  defined  as  follows: 

procedure  P^(.^i ,  ^  b 

t  :  =  0 

call  P\x2y'- 
call  P^(X2,*-', 

Xi  :=  JC)  +  1 

end 

To  present  the  idea  behind  the  construction,  we  first  discuss 
the  case  of  P^.  The  SDG  for  program  P^  can  be  depicted  as 
shown  below.  (We  use  the  labels  X/  and  x/,  for  1  <  /  <  3,  to 
denote  corresponding  formal-in,  formal-out,  actual-in,  and 
actual-out  vertices.  To  enhance  readability,  formal-in  and 
actual-in  vertices  are  shown  ordered  right-to-left  (X3  X2  Xj) 
rather  than  left-to-right  (x^  X2  X3).) 


"1^2  "3 

i  V  v 


A  A  , 


"3  ^2 


!  !  !  P 

^3  '^^2 


I  2  3 


Now  consider  a  slice  of  program  P^  with  respect  to  the 
formal-out  vertex  for  parameter  X3  (/.e.,  P^.xf).  To  com¬ 
pute  this  slice,  the  Hwang-Du-Chou  method  performs 


actions  that  are  equivalent  to  carrying  out  a  traversal  of  an 
exponentially  long  path  in  a  complete  binary  tree  of  height 
3.  The  path  traversed  is  shown  in  bold  in  Figure  8. 

If  we  examine  the  tree  of  Figure  8  more  closely,  it 
becomes  apparent  that  the  original  slicing  problem  spawns 
two  additional  slicing  problems  of  very  similar  form.  These 
two  subsidiary  problems  involve  performing  slices  of  the 
program  with  respect  to  P\>xf  and  P2-^2"»  where  Pi  and 
P2  are  the  two  children  of  the  root  of  the  tree.  Each  of  these 
subsidiary  slicing  problems  is  equivalent  to  taking  a  slice 
with  respect  to  the  formal-out  vertex  P^.  X2'  in  program  P^. 

In  general,  the  Hwang-Du-Chou  algorithm  takes  expo¬ 
nential  time  on  the  family  of  programs  P^.  To  perform  a 
slice  with  respect  to  formal-out  vertex  P^.  X}^\  the  algorithm 
performs  actions  that  are  equivalent  to  traversing  an  expo¬ 
nentially  long  path  (/.e,  a  path  of  length  Q(2^))  in  a  com¬ 
plete  binary  tree  of  height  k.  To  perform  the  slice  with 
respect  to  formal-out  vertex  P^.xjf,  the  algorithm  spawns 
two  subsidiary  slicing  problems  that  are  equivalent  to  per¬ 
forming  slices  with  respect  to  formal-out  vertex  P^"  ‘ .  X;t- 
in  program  P^”*.  (In  addition  to  the  two  subsidiary  slices, 
three  additional  edges  are  traversed.)  Thus,  the  time  com¬ 
plexity  of  the  Hwang-Du-Chou  algorithm  is  described  by 
the  following  recurrence  relation: 

T{k)--2T{k-\)  +  3 

P(I)=  1 

Therefore,  T{k)  =  2^^’  -  3  =  0(2*).  □ 
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